ENTERPRISE MANAGEMENT APPLICATION PROVIDING AVAILABILITY CONTROL 



CHECKS ON REVENUE BUDGETS 



BACKGROUND 

[1] "Enterprise management applications" f EMAs") refer generally to a class of computer 

systems that organizations use to manage their operations. For example, to generate a 
purchase order or invoice in the course of an organization's business, the organization may 
compel their employees to engage an EMA and enter appropriate information representing the 
transaction to be performed. The EMA not only would generate the purchase order or invoice in 
question, it would validate the transaction being performed to ensure that it complies with 
predetermined procedural controls established by the organization and also would record data 
representing the transaction for integration with its financial applications, among others. 

[2] Availability Control f AVC") systems perform one such validation operation. AVC systems 

validate expenditure transactions (e.g., purchase orders, vendor payments, payroll payments 
and the like) by comparing them to organizational budgetary requirements before validating the 
transaction. In this regard, the operation of EMA systems is well known. 

[3] Conventional AVC systems do not operate on revenue-generating transactions. For 

example, if an organization were to generate a customer invoice for performance of some 
service, no AVC check is performed because most organizations accept revenue from whatever 
sources are available. 

[4] Some organizations, however, particularly public sector organizations or non- 

governmental organizations (NGOs), are not free to accept revenue from any source that 
becomes available to it. Public sector organizations for public policy reasons, legislative 
proscription or other reasons, may choose to limit revenue that they receive to within 
predetermined limits. For example, a public sector organization may own some piece of 
equipment (e.g., a wind tunnel). If the organization were established for purposes of academic 
research, it may choose to lease use of the equipment to others to help sustain its operations. 
At the same time, it may choose to limit revenues it earns from such leases to remain faithful to 
its charter as an organization devoted to research. 
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[5] In another example, an NGO may solicit grants from various donor organizations to 

support its operations. At the same time, the organization may limit the grant revenue that it 
receives from any single donor to maintain independence from that donor organization. 

[6] The inventors perceive a need in the art for an EMA system that manages revenues as 

they are received by an organization to compare them with predetermined requirements 
established for the organization. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[7] FIG. 1 is a functional block diagram of a revenue-based AVC control system 100 

according to an embodiment of the present invention. 

[8] FIG. 2 illustrates a budget data structure for use with a posting ledger database or a 

budget ledger database according to an embodiment of the present invention. 

[9] FIG. 3 illustrates an exemplary AVC rule set according to an embodiment of the present 

invention. 

[10] FIG. 4 is a flow diagram of a method according to an embodiment of the present 

invention. 

[11] FIG. 5 is a simplified block diagram of a processing system suitable for use with the 

present invention. 

DETAILED DESCRIPTION 

[12] FIG. 1 is a simplified functional block diagram of an EMA system 100 according to an 

embodiment of the present invention. The EMA system 100 is shown as including a transaction 
manager 110, a transaction database 120, an AVC manager 130, one or more AVC ledgers 140- 
1, 140-2, 140-N, a revenue postings ledger database 150 and a revenue budget ledger 
database 160. Operators at terminal T interface with the EMA 100 via a communication network 
and generate various transactions, which are recorded in the transaction database 120. As is 
known, EMA systems 100 commonly include modules to manage human resources processes, 
materials management processes, financial processes and the like; such modules may be 
considered part of the transaction manager 110 for the purposes of the present discussion. 
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Accordingly, the transaction manager 110 also includes conventional modules that manage 
revenue-generating events such as sales processes, financial accounts receivable management 
and the like. 

[13] The AVC manager 130 is an application that performs revenue-based AVC checks and 

implement responses thereto. The AVC manager 130 is supported by the revenue postings 
ledger database 150 and the revenue budget ledger database 160. The revenue postings ledger 
database 150 may store revenue items generated from various transactions performed by the 
organization and already admitted to the EMA system 100. The revenue budget ledger database 
160 may include revenue budget items representing a budget defined for the organization. 
When a new transaction is proposed to the EMA system 100, the AVC manager 130 may refer 
to posting and budget items within these respective databases 150, 160 to determine if the new 
transaction is consistent with the limitations embodied by the various AVC rules. 

[14] The AVC rule set 142-1 includes control objects that represent the aggregation objects 

where defined AVC rules of the present invention are applied. These control objects may refer 
to aggregated revenue items and budget items, which may be found in the postings ledger 
database 150 and the revenue budget ledger database 160. The AVC ledger 140-1 also may 
include databases 144-1, which may store copies of the revenue postings and budget items. 
Thus, whereas the ledgers 150/160 may include items for all revenue postings/revenue budget 
admitted to the EMA system 100, the AVC database 144-1 may include aggregated values of 
the revenue postings/revenue budget items that are relevant to the control objects in the AVC 
rule set 142-1 to which the AVC database 144-1 corresponds. In this sense, the AVC database 
144-1 may represent an 'aggregated view' into the revenue-generating transactions and 
revenue budget entries that are relevant to the control objects of the respective ledger 140-1. 

[15] During operation, when new revenue items or new budget values are proposed to the 

EMA system 100, the AVC manager 130 may execute the various AVC rules. If an error is 
generated therefrom, the AVC manager 130 may cause the transaction manager 110 to reject a 
proposed transaction that causes the error. Data representing admitted transactions may be 
stored in a variety of storage locations, including the transaction database 120, the postings 
ledger database 150, the budget ledger database 160, and any AVC ledger databases 144-1, 
144-2, 144-N to which the admitted transaction is relevant. 
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[16] The AVC management features might best be understood with reference to an example 

involving a hypothetical organization. Consider an organization composed of departments A, B 
and C. Department A may include sub-departments Al and A2, department B may have no sub- 
departments and department C may have sub-departments CI, C2, C3, C4 and C5. FIG. 2 
illustrates an exemplary budget data structure that might be used in connection within this 
organization to record revenue budget data. Revenue budget information may be recorded in 
one or more databases, organized not only by the department or sub-department to which the 
transaction relates but other dimensions including, for example, various projects for which 
revenue is expected to be earned or various assets (e.g., specialized equipment) for which the 
revenue is earned. 

[17] The budget data structure 200 of FIG. 2, therefore, may include various budget nodes 

to represent various dimensions along which revenue is to be recognized. Thus, the budget 
data structure includes budget nodes for department A, sub-departments Al and A2 and 
revenue types Al.l, A1.2, A2.1, A2.2, A2.3 and A2.4. Some revenue types may be common to 
many different sub-departments but others may be unique to individual sub-departments. The 
architecture of the budget data structure depends on the business requirements of the 
organization it represents rather than any requirements imposed by the EMA system. 

[18] Although the budget data structure shown in FIG. 2 has been described in connection 

with the revenue budget database 160 of FIG. 1, the posting ledger database 150 may possess 
the same structure. When employed for postings, individual nodes of the budget data structure 
may store data representing revenue items posted by an EMA system as are relevant to the 
budget data structure. Thus, where the budget database 160 may store budget values 
developed according to a planning phase of the organization's operations, the posting database 
150 may store revenue items representing revenue values recorded during the operations 
themselves. 

[19] FIG. 3 illustrates exemplary AVC rules 310-1, et seq., for use with the budget data 

structure of FIG. 2, according to an embodiment of the present invention. The AVC rules may 
include address fields 320 that point to data items in the posting database and the revenue 
budget database. They also may include a test field 330 that identify a relationship between the 
addressed data items that must be met to pass the associated rule. Further, the AVC rules may 
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include a response field 340 that identifies an action to be taken if the AVC rule is violated. For 
each AVC rule a control object (in FIG. 3 listed left of the rule set table) is associated. The 
control object may be derived from the source addresses 320. It represents a storage location 
in the AVC ledger databases 144-1, 144-2, 144-N. 

[20] In embodiments where the posting database and the budget database employ identical 

budget data structure, it can be sufficient to use a single address field to address items in each 
database 150, 160. This may occur when revenue postings at predetermined dimensions of an 
organization are to be compared to budgetary values at the same dimensions. Of course, the 
principles of the present invention are not so limited. In other embodiments, control objects 
may include two types of address fields, one set of addresses referring to elements of the 
posting database and another referring to elements of the budget database. 

[21] According to other embodiments of the present invention, a control object may specify 

an aggregation scheme to employ among various addressed entries in the postings database, 
the budget database or both. For example, one control object may specify a straight summation 
of revenues and revenue budget values obtained from budgetary nodes A2, A2.1, A2.2, A2.3 
and A2.4 before comparing these aggregated values against each other as specified in the test 
field. Control objects of other embodiments might specify a weighted summation or may permit 
a posted revenue to be included in a summation only if it meets some predetermined filtering 
criterion. Thus, the AVC system of the present invention provides a flexible computational 
scheme to fit different needs of the organizations that may use it. 

[22] According to another embodiment of the present invention, several parallel AVC ledgers 

140-1, 140-2, 140-N may be used to include different sets of AVC rules and control objects. 
Provision of multiple ledgers permits an organization to engage in a variety of different 
revenue-based AVC checks, which might be defined independently and implemented in parallel. 
When a revenue transaction is received, an identifier of the donor organization may be 
compared to the filtering conditions of the various AVC rules sets 142-1, 142-2, 142-N (FIG. 1) 
and, if a match occurs, the AVC rules of the matching AVC rule set may be executed. 

[23] As noted, an AVC database (say, 144-1 FIG. 1) within an AVC ledger 140-1 may store 

aggregate data representing control objects and operands of the AVC rule test field 330 in the 
corresponding AVC rule set 142-1 and either the transaction data underlying such aggregates or 
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pointers thereto. As such, an AVC ledger database establishes subsets of larger general 
transaction databases that commonly are used in an EMA system. For those operators that 
work with the control objects and the AVC rules, an AVC ledger database can become a 
convenient database with which to work. The operators may perform searches through the AVC 
ledger database in performance of their duties. In general, such ledger databases, although 
they may become large (e.g., recording thousands, tens of thousands or even hundreds of 
thousands of transactions) typically will be much smaller than the general transaction databases 
(recording perhaps millions of transactions). Thus, in EMA systems where it may be preferable 
to perform online database checks, requiring search results to become available in a near real 
time fashion, this reduction in size of the databases to be searched can be very useful. 

[24] FIG. 4 is a flow diagram of a method according to an embodiment of the present 

invention. According to the method, when a new revenue item is entered, the EMA system 
determines whether the revenue item is addressed by any control object of the AVC rule sets 
established (boxes 410-420). If so, the EMA system executes all AVC rules linked to the control 
object(s) (box 430). As noted, violation of an AVC rule may cause either an error or a warning 
as a response. If any AVC rule generates an error, the EMA system may block the revenue item 
from being admitted (box 440). If no AVC rule generates an error but one or more AVC rules 
generate a warning, the EMA system may generate a warning notification as dictated in the 
respective AVC rule(s) (box 450). Thereafter, or if the revenue item does not violate any AVC 
rule, the EMA system may admit the new revenue item (box 460). 

[25] Consider the revenue AVC system in operation. As described above, an organization may 

decide as a matter of policy that it will permit leases of its equipment up to only a certain 
percentage of its expected revenue. For example, the organization may design the following 
policies for revenue: 

• generate an error if the lease revenues for any single piece of equipment of a certain 
type (e.g., A2 and its subordinate nodes) meets or exceeds 50% of the revenue 
budget for such piece; 

• generate a warning of the total lease revenues for all pieces of another type of 
equipment (e.g., Al and its subordinate nodes) reaches 30% of the total of revenue 
budgets for such pieces of equipment; and 

• generate an error if the total lease revenues for all pieces of this type of equipment 
reach 40% of the total revenue budget for such pieces of equipment. 
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The exemplary control objects and AVC rules of FIG. 3 might be established to accommodate 
such a policy. Within the postings and budget structures, nodes A2.1-A2.4 might represent 
respective revenues and budgets attributable to four separate pieces of equipment owned by 
the organization. The control objects of FIG. 3 may establish AVC rules that govern revenue for 
such organizations. 

[26] Consider, as a further example, a scenario where postings values and budgetary values 

are established (using the budget data structure of FIG. 2) as shown in Table 1. 



NODE 


POSTINGS VALUE 


REF BUDGET VALUE 


A1 


0 


90 


A1.1 


10 


0 


A1 .2 


10 


10 ! 


A2 


0 


10 


A2.1 


0 


25 


A2.2 


10 


25 


A2.3 


10 


25 


A2.4 


10 


25 



Table 1 



Operation of the control objects of the AVC rule set of FIG. 3 would generate operand values as 
shown in Table 2. 



CONTROL OBJECT 


POSTINGS OPERAND 


BUDGET OPERAND 


A1 


20 


100 


A2 


0 


10 


A2.1 


0 


25 


A2.2 


10 


25 


A2.3 


10 


25 


A2.4 


10 


25 



Table 2 



Here, the postings operand for each control object represents the sum of all postings revenues 
referenced by the control object and the budget operand represents the sum of all revenue 
budget values referenced by the same control object. 

[27] If a new transaction were proposed that would increase revenue of node Al.l to 25 and 

of node A2.2 to 15, then operation of the control objects would occur as shown in Table 3. 
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CONTROL OBJECT 
(AVC RULE) 


POSTINGS OPERAND 


BUDGET OPERAND 


RESULT 






inn 








inn 


VVdl I Hi ly 


A2 (310-3) 


0 


10 




A2.1 (310-4) 


0 


25 




A2.2 (310-5) 


15 


25 


Error 


A2.3 (310-6) 


10 


25 




A2.4 (310-7) 


10 


25 





Table 3 



As shown above, the AVC rule 310-5 for control object A2.2 would be violated because the 
postings value in node A2.2 is more than 50% of the budget value for the same node. In this 
case, control object A2.2 (AVC rule 310-5) would generate an error and the transaction would 
be blocked. Additionally, an AVC rule for control object AI (310-2) would be violated because 
the postings operand (the sum of all values in nodes AI, Al.l and A1.2) exceeds 30% of the 
budget operand. The AVC rule for control object AI (AVC rule 310-2) would generate a warning 
notification, which by itself would not cause rejection of the proposed revenue postings. 

Consider another transaction, which increases the posting value of node A1.2 to 40 and 
of node A2.1 to 12. 



CONTROL OBJECT 
(RULE) 


POSTINGS OPERAND 


BUDGET OPERAND 


RESULT 


A1 (310-1) 


50 


100 


Error j 


A1 (310-2) 


50 


100 


Warning 


A2 (310-3) 


0 


10 




A2.1 (310-4) 


12 


25 




A2.2 (310-5) 


10 


25 




A2.3 (310-6) 


10 


25 




A2.4 (310-7) 


10 


25 





Table 4 



Thus, the transaction would be rejected because the postings operand of the control object AI 
(AVC rule 310-1) is more than 40% of the associated budget operand, resulting in an error 
message from AVC rule 310-1. However, the system would in this case not issue the warning 
message from violation of the AVC rule 310-2, because the same control object AI is 
concerned. 
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The foregoing discussion has presented AVC checks operating in the context of 
proposed transactions that increase posted revenue. In an embodiment, the principles of the 
present invention also find application for transactions that modify revenue budget as well. An 
operator at terminal T (FIG. 1) may propose a transaction to the EMA system 100 that would 
cause a reduction in revenue budget for a particular entity within an organization perhaps as a 
transfer of revenue budget between entities of an organization. In response, the transaction 
manager 110 may cause the AVC manager 130 to execute AVC rules from among the AVC rule 
sets 142-1 to 142-N. A violation of any AVC rule may indicate that the proposed budget revision 
violates a revenue constraint policy established for the organization or revenue entries already 
admitted to the system. In response, the AVC manager 130 may cause the transaction manager 
110 to reject the proposed budget revision. 

The foregoing embodiments may provide a software implemented AVC system. As such, 
these embodiments may be represented by program instructions that are to be executed by a 
server or other common computing platform. One such platform 500 is illustrated in the 
simplified block diagram of FIG. 5. There, the platform 500 is shown as being populated by a 
processor 510, a memory system 520 and an input/output (I/O) unit 530. The processor 510 
may be any of a plurality of conventional processing systems, including microprocessors, digital 
signal processors and field programmable logic arrays. In some applications, it may be 
advantageous to provide multiple processors (not shown) in the platform 500. The processor(s) 
510 execute program instructions stored in the memory system. The memory system 520 may 
include any combination of conventional memory circuits, including electrical, magnetic or 
optical memory systems. As shown in FIG. 5, the memory system may include read only 
memories 522, random access memories 524 and bulk storage 527. The memory system not 
only stores the program instructions representing the various methods described herein but also 
can store the data items on which these methods operate. The I/O unit 530 would permit 
communication with external devices (not shown). 

Several embodiments of the present invention are specifically illustrated and described 
herein. However, it will be appreciated that modifications and variations of the present 
invention are covered by the above teachings and within the purview of the appended claims 
without departing from the spirit and intended scope of the invention. 
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